Agile Adoption Patterns: A Roadmap to Organizational Success by Amr Elssamadisy

Author:Amr Elssamadisy
Language: eng
Format: epub
Publisher: Addison-Wesley
Published: 2009-07-01T16:00:00+00:00

Adopt collective code ownership to support team development. This will enable you to always fix tests when they are broken.

Consider adopting pair programming as a support practice to ease the learning curve for the team. It is easier to be disciplined about tests when you are working with someone else.

Start writing tests with the current iteration. Expect a slowdown of up to 50 percent if you are working on a new project. If you are on a project that already has a large amount of untested code, your slowdown will be more pronounced. Your testing time will go down over time to about 20 to 30 percent of the total development effort. You will eventually hit a “critical mass” point where existing tests can help you write new code. This will speed up your overall development time. Believe it or not, you will develop faster even with the testing overhead!

Within a few iterations, your team will come up against the problem of setup data. As you write objects that rely on other objects, which in turn rely on even more objects, the amount of code written to “set up” for a test increases. There are two approaches to this problem: Pull out the common setup code into common classes. These classes are responsible for creating classes and test data; they are a special type of factory. They also create business objects in a given state. Martin Fowler gives a brief overview and links to the original ObjectMother paper presented at XPUniverse 2001 at www.martinfowler.com/bliki/ObjectMother.html. ObjectMother is a common evolution of complex setup code. Your tests are always exercising real business objects, which is good. On the other hand, the ObjectMother creates a maintenance burden that can easily become unwieldy from supporting too many special cases. Tests based on this solution may become brittle because one test relies on many business objects. They also can become slow, and slow tests aren’t run. Be careful.

Use mocks and stubs to keep away from the complexity of ObjectMother. Mock objects and stubs are placeholders for the business objects under test. They can be used to cut off the thread of one object pulling another several objects for testing purposes. A good paper describing the correct use for mocks and stubs is “Mock Roles, Not Objects” (www.jmock.org/oopsla2004.pdf), which was written by the group who created the jMock framework. Mocks can be used to make your tests much more readable and less fragile. On the downside, mocks are a form of duplication. A proper mock object mirrors the business object it mocks, which can be dangerous. If the business object changes, a mock must change also; if it does not, a test will continue to pass even though it should really fail.

c. Both approaches—mocks and ObjectMother—work well. The important part is consistency. Agree as a team on an approach and follow it. This will make it easier for team members to work with each other’s code.

Always use mock objects and stubs to test classes that communicate with external systems.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.